Business objects contain data stored in different tables within a database. Such a database structure can be used for general-purpose querying while being generally free of certain undesirable characteristics such as insertion, update, and deletion anomalies.
One technique for retrieving business objects from a database is referred to as “retrieve by association”. With retrieve by association, each table for a particular business object is separately selected and each such selection requires a full roundtrip between the database server and the requesting client. The business object is then rebuilt on the client side. As an object can consist of over 70 tables, there can be a corresponding number of round-trips (e.g., 70+) to the database server. Optimization techniques cannot be applied in such situations as it is not always clear which tables contains relevant data for the business object. In addition, because of this issue, requests cannot always be parallelized.
FIG. 1 is a diagram 100 illustrating a conventional database structure in which the data of a first level 110 will be requested first. The first level 110 always comprises only one table, namely, the root-table. At this point, all the data from the second level 120 can be requested, with a single request per table. These requests can be performed in parallel. With the data from the second level 120, the data from the third level 130 can be requested, and so forth. As can be appreciated, data from the previous level is always required. Such a cascading arrangement can consume significant resources in connection with data transport as well as client-side processing of the transported data.